<html>
<body>
<p>DTOs for the booking client facade.</p>
<p>DTOs are designed in a use case-driven fashion, closely related
    to the service layer interface. They represent a particular section of
    the domain model, which may cross aggregate boundaries. They have no
    business logic and are immutable.</p>
<p>The reason for using DTOs is mainly to loosen the coupling of
    the application and the user interface. It allows us to build the
    domain model completely without having to conforming to any UI-related
    conventions or requirements, such as JavaBean getter methods or
    no-args constructors. We also avoid exposing functionality that is
    internal to the domain model to the UI layer.</p>
<p>Furthermore, we have a clear contract for what part of the
    object graph is loaded from the database when the service layer call
    returns. If domain model objects are passed on to the UI layer, it
    will be necessary to keep the database access window (e.g. the
    Hibernate session) open during the entire processing of the view (the
    Open Session In View pattern), otherwise an uninitialized part of the
    model could accidentally be accessed, causing an error. For example,
    if the UI layer were to receive a Cargo instance, that could be
    navigated to access the Itinerary, iterate over the Legs of the
    itinerary, access the Leg's CarrierMovement and then the
    CarrierMovement's Location and so on. In addition to effectively tying
    the UI layer and the rest of the application to the same JVM, letting
    the UI layer decide when to initialize data may be very inefficient.
    DTOs are a natural way of loading only the relevant data for a
    particular use case, and blocking access to the rest.</p>
<p>Using DTOs also makes the service layer reusable across
    different kinds of front-ends: web, rich clients, other back-end
    systems etc. Remember that classes that are persisted with Hibernate
    or similar technologies are modified in runtime, so that for example
    collection-valued fields are swapped for customized implementations
    that allow lazy loading. If these persisted domain model classes are
    to be de-serialized in another JVM, those O/R-mapping-specific classes
    need to be available there as well, which is not very elegant.</p>
<p>A caveat to consider: The usefulness of DTOs may vary with the
    degree of vertical separation in the application. If it's very
    unlikely that your application will use anything other than a web
    interface, and that it otherwise are no problems running the web layer
    together with the rest of the application, you may want to avoid the
    overhead of maintaining several similar sets of classes.</p>
</body>
</html>